1. Field of the Invention
The invention concerns object-oriented programming systems in general and object-oriented programming systems for generating graphical displays in particular.
2. Description of the Prior Art
Sharp declines in the cost of memory and processing power has made it possible for even low-cost computer systems to provide graphical user interfaces to their users. In typical systems with graphical user interfaces, the display is divided into a number of windows of varying sizes. Some of the windows show the output of programs being executed for the user; others display icons, menus, buttons, sliders, and the like. The user of the system can employ a pointing device such as a mouse to control the operation of the system by selecting icons or menu items or operating buttons or sliders and can employ a keyboard to input characters to windows.
While a graphical user interface makes it easier for a user to work with a program, the graphical user interface adds substantially to the program""s complexity, and therefore to the difficulty of writing the program. Efforts to simplify the task of writing programs involving graphical user interfaces have led to the development of systems for programming graphical user interfaces. An example of such systems is the X Window System, described in Robert W. Scheifler, James Gettys, and Ron Newman, X Window System, C Library and Protocol Reference, Digital Press, 1988, and in Paul J. Asente and Ralph R. Swick, X Window System Toolkit, Digital Press, 1990(X Window System is a trademark of the Massachusetts Institute of Technology).
FIG. 1 shows a computer system 101 which employs the X Window System. The hardware components of computer system 101 are processor 121, memory 103, display 131, keyboard 137, and mouse 139. Mouse 139 controls the position of pointer 133 in display 131. Processor 121 is executing an application process 109 which is executing an application program 110. Application program 110 is displaying two windows 135, window 135(a) and window 135(b) in display 131. During execution, data and instructions flow between memory 103 and processor 121, as indicated by arrow 119 and outputs to display 131 flow from processor 121 to display 131, as indicated by arrow 123. Inputs flow from keyboard 137 and mouse 139 to processor 121 as indicated by arrows 125 and 129.
Application program 10 has been implemented using the X Window System; consequently, program 110 has four major components: application code 111, the specific code for the application program, and three components of the X Window System: widgets 113, Intrinsics 115, and XLIB library routines 117. The XLIB library routines are what actually cause windows and their contents to appear in display 131; when an XLIB library routine is executed by processor 121, processor 121 sends a message specifying an operation on display 131 to another component of the X Window System, server process 105, which executes X server code 107. Server process 105 responds to the message by performing the actual operations which produce the windows 135 in display 131. Server process 105 further detects events such as inputs from mouse 139 or keyboard 137 and sends messages specifying the events to application process 109, which responds to the event messages by executing callback functions (CBF) 112 code in application code 111.
While XLIB library routines can be invoked directly by application code 111, the library routines are still too low-level to permit easy programming of graphical user interfaces. To deal with this difficulty, the X Window System has provided programmers with a toolkit for programming in the system. Intrinsics 115 and widgets 113 belong to the toolkil
FIG. 2 is an overview of a widget 201. Functionally, widgets 201 mediate between application code 111 and X server code 107. When application code 111 wants to change the state of a window associated with a widget, application code 111 writes values in the widget; in response to the change, widget 201 performs actions which result in messages being sent to X server 107 to change the state of the window. When X server code 107 receives an event concerning a window, X server code 107 sends the event to the widget 201 for the window. Widget 201 then performs the actions required for the event. Among the actions may be invocation of a callback function 112. Once a class of widgets has been defined, any application program to which the definition of the class is available may create and use widgets belonging to the class.
Widgets 201 are compiled objects. An object is a data structure and a set of functions which represent an entity manipulated by a computer program. The data structure represents the state of the entity. Some of the functions permit the program to write and read parts of the data structure; others of the functions respond to changes in the data structure. The functions associated with an object determine how the object behaves and thus determine the object""s class (type). The classes of widgets 201 are hierarchical. If a class is below another class in the hierarchy, it inherits the characteristics of the class above it, and widgets belonging to the class have the inherited characteristics as well as those particular to its own class.
A compiled object is an object whose class and data structures are defined at compile time, that is, when the code which describes the object is compiled. Objects may also be interpreted; with such objects, the class and data structures of the object are defined at run time, that is, when the program using the object is executed. Compilation permits better type checking and more efficient code generation than interpretation, and consequently, systems using compiled objects are generally more efficient and have fewer bugs than systems using interpreted objects; however, compiled objects are generally less flexible. When a compiled object is created and used at run time, the values contained in the object""s data structures may vary, and what happens when a function is executed may depend on the values in the data structures, but the data structures and functions themselves cannot change. In terms of widget 201, the fact that widget 201 is a compiled object means that widget 201 can be used only to represent the kind of window 135 corresponding to the widget""s class, not to represent any window.
Returning to the details of widget 201, the hierarchy of classes appears in FIG. 2 as superclass field 203, which contains the name of the class of which widget 201 is a subclass. Widget 201 inherits all of the functions of the class specified in field 203, which inherits all of the functions specified for its superclass, and so on. Class 205 is the name of the widget""s own class.
Methods 207 are functions which define the widget""s class. All widgets belonging to a class employ the same methods 207 to carry out the operations which define the class. The methods may either be defined specifically for the class or inherited from classes higher up in the hierarchy. For example, windows are often hidden and exposed again in the course of operation of a windowing system, and consequently, most widget classes have methods which specify what is to be done when a window 135 associated with a widget belonging to the class is exposed. When a specific window is exposed, the widget for that window uses the expose method for its class to redraw the window. Of course, redrawing the window may require the method to call X functions in Intrinsics 115 and/or XLIB 117.
Resources 209 are values in widget 113 which represent the state of the widget. What resources a widget 113 has is determined by its class. The values of the resources are of course determined at run time. Both application code 111 and routines in methods 207 can read and set values in resources 209, and routines in methods 207 can respond to changes in values in resources 209 by calling X functions or by calling call back functions 112. The resources thus provide a way of communicating between application code 111 and the X Window System. For example, if a window 135 is to display a line of text, the application code 111 writes the line of text to a resource in the window""s widget and a method in the widget reads the line from the resource and calls the X functions necessary to cause the line to be displayed in the window 135. Similarly, when pointer 133 is located in a window and the user of system 101 clicks a mouse button, X server 107 responds to the mouse click by sending an event message to widget 201 for the window. The arrival of the event message results in the execution of a method and the method may change a value in resources 209. If the change in the value requires that a callback function be executed, the method invokes the callback function, which can then examine the values in resources 209 and respond to the event accordingly.
Callback function specifiers 211 specify functions in callback functions 112. As just described, methods call callback functions when a change in the state of resources 209 so requires. The callback functions which application code 111 may provide for a widget 209 are of course determined by the widget""s class. Intrinsics 115 are X Window System functions which permit programmers to define widgets and which implement the interfaces between application code 111 and a widget on one hand and between X server 107 and the widget on the other. For example, an intrinsic function invokes the method used by the widget to set its resources and another intrinsic function invokes methods used to deal with event messages from X server 107.
While programming systems like the X Window System have made it much easier to program for graphical user interfaces, they are less flexible than might be desired. One reason for their lack of flexibility is the fact that widgets are compiled objects. While compilation provides more efficient code and better type checking than is possible otherwise, there are many occasions where the characteristics of the window are not known until application program 110 is actually executed. For example, a program cannot use widgets as they are presently known to arrange arbitrary graphical elements in a window. The programmer must either provide a separate widget for each arrangement of elements or directly employ the much more difficult interface provided by XLIB 117. Similar problems arise in any system employing compiled objects. It is an object of the invention to provide a compiled widget which retains the advantages of compilation but which can be used to arrange arbitrary graphical elements in a window. The techniques employed in this drawing widget may be used generally to create compiled objects which retain the advantages of compilation but achieve a flexibility which has been heretofore possible only with interpreted objects.
In the invention, flexibility is gained by providing a sequence of at least one invocation of a function to a compiled object at runtime. The sequence is stored in the object, and the invocations in the sequence are executed at appropriate times.
The foregoing technique is employed in an illustrative embodiment to implement a drawing widget for the X Window System. A resource in the drawing widget specifies graphical elements to be drawn in the window represented by the widget. To draw an element in a window represented by a drawing widget, application code 111 first uses a routine in the Intrinsics to make a sequence of the invocations of primitive drawing functions in XLIB 117 which are required to draw the element in the window available to the widget. This is done for each element in the window. Then application code 111 uses another routine in the Intrinsics to invoke the method function in the drawing widget which sets the resource. The method function sets the resource 209 to the invocations in the sequence. The expose method for the widget then executes the invocations in the resource 209. As a result of the execution of the invocations, the elements appear in the window represented by the widget.
Of course application code 111 may obtain the sequence of invocations from a source external to application code 111, such as a file or a pipe connected to another process. Application code 111 may also provide invocations to the sequence in direct response to inputs from mouse 139 and/or keyboard 137 in the window in which the elements are being displayed, thus permitting interactive drawing in the window.
In a preferred embodiment, the resource may also be set to specify invocations of functions which scale, rotate, and translate the elements in the window represented by the widget. For ease of use, the invocations provided by application code 111 in a preferred embodiment are represented as character strings which specify the name of the function being invoked and the actual arguments used in the invocation. Efficient operation of the widget is ensured by translating the character strings into integer and floating point values when the resource is set.
Further advantages include the use of a unit coordinate system to represent coordinates in the invocations and invocations specifying scaling, rotation, and translation functions. A transform function converts the unit coordinates to the pixel coordinates used in the actual X Window graphics primitives. Scaling, rotation, and translation are done by specifying the amount of scaling, rotation, or translation as arguments in the relevant functions. The transform function then uses these arguments to compute the pixel coordinates from the unit coordinates. Scaling is also done whenever the dimensions of the window represented by the widget change. To ensure that changes to the resource are immediately reflected in the window, the method which sets the resource also redraws the window where necessary.
The foregoing and other objects and advantages of the invention will be apparent to one of ordinary skill in the art who peruses the following Drawing and Detailed Description, wherein: